A service provider responding to client requests from a number of web based applications needs more than one server. The service provider distributes tasks requested by clients to applications across an array of individual servers, called server clusters. Clients make requests to applications running on the individual servers in the server cluster through a web browser in order to receive results from the applications. The sending of requests, and the receiving of results take place in a series of Hypertext Transfer Protocol (HTTP) communications between the client and the server, called sessions. Examples of a session include selecting and purchasing goods from an online retailer or performing a series of banking transactions.
The provider of the server cluster maintains HTTP session state by employing a mechanism so that individual HTTP clients are sent to the same server across multiple requests in a session. When a specific server is assigned to a specific client, the relationship between the server and the client is called affinity, and the assigned server is called an affinity server.
As additional clients access the server cluster, new sessions will be created between the clients and assigned servers. If too many sessions are assigned to a single server, the server may become overloaded causing a range of performance problems including system failure. Therefore, new sessions will be distributed to different servers across the server cluster to balance the server load within the server cluster. The distribution of sessions across the different servers on a cluster is called load balancing.
Load balancing across multiple servers is known. Oliver Matsutti, in “Distributed Web Session Management,” (Master's Thesis, 2000) discloses using an HTTP Redirect command for assignment of a client's request to a different server from that to which the request was directed. Matsutti's software resides on the web server, and the decision to redirect the request is made at the web server which functions as a router to select the destination application server.
When redirection is initiated at the router level, a problem arises when multiple routers are employed. In a live, distributed system, each individual router instance must pick the same alternative destination. In other words, different routers must have the same data at a given instance. Timing issues may occur in transferring the state information necessary for multiple routers to distribute multiple requests for a given session to the same newly selected server. A commonly known solution to address such timing issues is a distributed locking mechanism.
Specifically, the distributed locking mechanism coordinates the state information in each router so that each router makes the same decision as to where to send a request. But the distributed locking mechanism requires extensive code to be written to coordinate the actions of the routers.
In addition to the problem of coordinating the routers, servers may be added to or deleted from the server cluster, new applications may be installed on an existing server in the cluster, or the weight given a particular server for load balancing may be changed. Therefore, another problem that arises when rebalancing among individual servers in a cluster is to account for changes in the server cluster configuration.
Therefore, a need exists for a mechanism to rebalance sessions across individual severs in a cluster without the need to write code to coordinate multiple routers and to account for changes in the configuration of the server cluster.